Today it is very common that information is sent over computer networks. The amount of information being sent is rapidly increasing due to the advances in technology, making it possible to send and handle more information at higher speed. Furthermore, new applications demand a higher amount of information.
Example computer systems where data transmission is quite important include electronic trading systems. Today, electronic trading of securities, derivatives, commodities and other financial instruments involves large amounts of order transactions transmitted to and from users of the electronic trading system. Furthermore the users connected to a centralized automated electronic trading system require low latency in the access to the system. In some cases it may not be enough to simply boost the performance in the central system by for example updating the hardware in order to get rid of a bottleneck or other latency problem in the system.
Moreover, some electronic trading systems allow different types of users to access the system. For example a fixed income market implemented in an electronic trading system can be configured to allow both primary users and secondary users to trade in the same instruments. The electronic trading system can for example be configured to let a primary user trade at the true trading price whereas a secondary user is charged an extra fee when using the system. The fee can typically be charged by adding an amount such as a tick when trading in the system. It is also common that the secondary users are hindered from seeing the real prices in the market. Instead the price displayed is the price including the additional charge. The extra fee that will be charged to a secondary user will then be applied to each price distributed from the market.
Below is an Example:
The electronic trading system has three different types of firms acting in the system.                Firm P_A—Primary customer A, users from this firm will be allowed to see the real prices in the market.        Firm S_B: Secondary firm B, users from this firm will not be allowed to the see the real market. They will instead see prices with an additional spread of 1 price tick.        Firm S_C: Secondary firm C, users from this firm will not be allowed to the see the real market. They will instead see prices with an additional spread of 2 price ticks.        
Security Y is traded with a price tick step size of 0.5.
The Real Market Prices are:
OfferBid sizeBidOffersize3100.0101.052100.0101.571099.5102.02
This will be the price picture displayed to users connected to customer P_A.
Based on the extra fee configuration the following view of the market for should be displayed to:
Customer S_B:—Additional Spread=1 pt=+/−0.5:
B. sizeBidOfferO. size399.5101.55299.5102.071099.0102.52Customer S_C:—Additional Spread=2 pt=+/−1.0:
B. sizeBidOfferO. size399.0102.05299.0102.571098.5103.02
The additional, off-set, spread values should have an effect on both pre-trade prices and post-trade prices. The price information is a very common field in a trading Application Program Interface (API) and it exists in most of the messages going in and out from the electronic trading system.
When generating and distributing the different orderbooks as shown above to the respective users a separate message to each type of firm must be generated. In the example above this would mean that the central system would need to generate 3 separate message flows, one for each firm.
Three separate messages are sent out from the system; one unique message for each type of user.
A typical trading system distributes a lot of different messages containing price information of some kind. With the solution described above it would mean that every message would need to be generated and distributed in three different ways which would have a major impact on both system performance and bandwidth impact on the network. Furthermore every customer type added to the system will add additional load to the system.
It would therefore be preferable to find a solution that requires less messages going out from the system regardless of the number of user types.
Hence, there exist a need for a method and a system that is able to accommodate for different orderbook interfaces for different types of users and at the same time reduce or eliminate the need for use of additional bandwidth resources.
The technology described in this application significantly reduces the amount of data needed to be transmitted from the central system when the central system is connected to users that are trading using different offset spread values.